Remarks 

Reconsideration of this application is respectfully requested. Claims 6-9, 23-25, and 
30-33 remain in the application. Claims 6, 8, 9, 23, 30, and 32 have been amended. No 
claims have been added or canceled. No new matter has been added as a result of these 
amendments as they are supported in Figure 2A and paragraphs 31, 35, and 37 of the 
specification as originally published. 

Examiner Interview 

Applicant wishes to thank the Examiner for the courtesy of a telephone interview 
on June 3, 2008, in which the Examiner indicated that the proposed amendments would 
overcome the current rejections. 

Rejecti ons under 35 U.S.C. 1 12 
Applicant's claims 6-9, 23-25, a nd 30-33 have been rejected under 35 U.S.C. § 112, 
first paragraph, as failing to comply with the written description requirement. Applicant 
respectfully submits that claims 6-9, 23-25, and 30-33, as amended, satisfy the written 
description requirement. In particular, as amended, Applicant claims a first interior 
gateway protocol (IGP) table comprising IGP forwarding entries for a first virtual private 
network (VPN) context and a second IGP table comprising IGP forwarding entries for a 
second VPN context. Applicant respectfully submits that these claims are supported in 
Figure 2A and paragraph 31, which discloses VPN context 109A having IGP table 2071 
and VPN context 109B having IGP table 207J. Accordingly, Applicant respectively 
requests the removal of the first paragraph 112 rejections. 

Rejections under 35 U.S.C. 103(a) 
Applicant's claims 6-9, 23-25, and 30-33 have been rejected under 103(a) as being 
rendered obvious by Rekhtar, et al., US Patent No. 6,339,595 in view of Alfieri et al., U.S. 
Patent No. 7,039,720 and Jagannath et al., U.S. Patent No. 7,095,740. Applicant does not 
admit that either Alfieri or Jagannath is prior art and reserves the right to swear behind 
either reference at a later date. Nonetheless, Applicant respectfully submits the 
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combination does not disclose each and every element of the invention as claimed in 
claims 6-9, 23-25, and 30-33, 

Rekhtar discloses creating multiple virtual private networks (VPNs) using edge and 
transit routers (Rekhtar, Abstract). A VPN is private wide-area network is a private 
network connecting remote customers network over a service provider's core network 
(Rekhtar, Fig. 1, col. 6, lines 17-25). Each edge router couples to one or more customer 
networks to act as the ingress or egress points with the customer's remote networks 
(Rekhtar, col. 2, lines 63-65). The transit routers forward the customer's VPN traffic within 
the service provider's core network (Rekhtar, col. 2, line 66- col. 3, line 7). 

The edge router identifies incoming traffic as belonging to a particular customer's 
VPN, tags the incoming traffic, and forwards the tagged traffic to the next hop transit 
router (Rekhtar, col. 2, lines 63-65). In one embodiment, each edge router has a separate 
forwarding information base (FIB) for each supported VPN , but has only a general FIB for 
all other non-VPN forwarding decisions (Rekhtar, col. 9, lines 27-35). In another 
embodiment, Rekhtar discloses that the edge router has a " common table containing VPN- 
identified entries " in instead of separate FIB tables for each VPN (Rekhtar, col. 33, lines 
36-41). In particular, Rekhtar discloses "... although we have described VPN-specific 
information being stored in separate tables because the approach seems most convenient, 
there in no reason in principle why a common table containing VPN-identifying entries 
could not be used instead ." (Rekhtar, col. 36, lines 36-41, emphasis added). Because 
Rekhtar used the word "instead", Rekhtar discloses that a single common VPN table 
approach is a replacement for the separate table per VPN approach. Nonetheless, Rekhtar 
does not teach or suggest a hybrid of the two approaches. 

Rekhtar's tag information base (TIB) contains next-hop information, tags, and tag- 
stack operations (Rekhtar, col. 10, lines 46-49). The tag is an index to a given router's 
routing table (Rekhtar, col. 9, lines 51-55). TIBs are modified using tag distribution 
protocols (Rekhtar, col. 11, lines 10-17). 

Thus, Rekhtar discloses VPN related routing information as (1) either a separate 
FIB table for each VPN or a common FIB table fo r all the VPNs; and (2) stored in a TIB. 
Nevertheless, Rekhtar does not disclose maintaining some VPN forwarding information in 
a common VPN Exterior Gateway Protocol (EGP) forwarding table and VPN Interior 
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Gateway Protocol (IGP) forwarding information in separate tables for each VPN. 
Furthermore, Rekhtar does not disclose the FIB table being updated from separate EGP 
and/or IGP tables. 

Alfieri discloses a dense virtual router packet switching system that divides the 
memory area into different context areas for a set of virtual private networks (Alfieri, 
Abstract). Alfieri further discloses a set of routing tasks that updates the single routing 
table of each context (Alfieri, Col. 5, lines 28-65). For example, " lelach context area 
contains a routing table and other operating state information for a different VR [ Virtual 
Router]" (Alfieri, Col. 5, lines 33-35). Furthermore, each "fclontext area CTXT 134 of the 
memory 62 contains the routing table and other operating state for this VR" (Alfieri, Col. 
5, lines 50-52). Alfieri further discloses one routing task for each routing protocol that are 
time-shared to handle routing requests for multiple VPNs (Alfieri, Fig. 5, Col. 5, lines 28- 
36). Each routing process connects to the VPN context and uses the one routing table of the 
VPN context through context selection logic (Alfieri, Fig. 5, Col. 5, lines 52-58). For 
example, " OSPF task 60-O performs operations in accordance with the received packet, 
which may include updating the routing table and initiating the transmission of one or more 
routing protocol packets to other routers in the VPRN" (Alfieri, Col. 5, lines 55-57). Thus, 
Alfieri discloses each VPN context having its own routing table. Nevertheless, Alfieri does 
not disclose the context forwarding table being updated from separate EGP and/or IGP 
tables. 

Jagannath discloses implementing VPNs using multi protocol label switching 
(MPLS) by placing the VPN identification (VPN-ID) in the MPLS label field (Jagannath, 
Col. 3, lines 8-13). In addition, the MPLS label is also placed in the MPLS label field 
(Jagannath, Col. 3, lines 8-13). Jagannath further discloses a router building a common 
MPLS table from separate VPN routing tables (Jagannath, Col. 3, lines 21-26; Col. 4, lines 
15-26). Forwarding of packets is performed by looking up the VPN- ID/MPLS label in the 
MPLS forwarding table (Id.). Alternatively, the packet VPN-ID identifies the a separate 
MPLS forwarding table used to forward the packet (Jagannath, Col. 3, lines 13-18; Col. 4, 
lines 7-14). Nevertheless, Jagannath does not disclose the context forwarding table being 
updated from separate EGP and/or IGP tables. 
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Applicant respectfully submits that the combination of Rekhtar, Alfieri, and 
Jagannath does not teach or suggest Applicant's claims. Rekhtar discloses VPN related 
routing information as ( 1 ) either a separate FIB table for each VPN or a common FIB table 
for all the VPNs ; and (2) stored in a TIB. Jagannath discloses a separate MPLS forwarding 
table for each VPN or a common MPLS table for all the VPNs. 

The Examiner asserts that Fig. 5 of Alfieri discloses that there are separate tables 
for each VPN context and for each routing protocol the context uses. Applicant respectfully 
disagrees. In Fig. 5, Alfieri discloses routing tasks (e.g. blocks 60-O, 60-B, and 60-R) that 
update a single forward table of each separate context. For example, Alfieri discloses 
" Each context area contains a routing table and other operating state information for a 
different VR [ Virtual Router]." Furthermore, the routing tasks update the VPN context 
routing table: " OSPF task 60-O performs operations in accordance with the received 
packet, which may include updating the routing table and initiating the transmission of one 
or more routing protocol packets to other routers in the VPRN" (Alfieri, Col. 5, lines 55- 
57). Thus, the routing tasks do not maintain a protocol specific routing table for each VPN 
context. Instead these protocol tasks maintain the one routine table for each VPN context 
(Alfieri, Fig. 5, Contexts 66; Col. 5, lines 33-35; and also Col. 3, lines 49-51). 

Therefore, none of Rekhtar, Alfieri, or Jagannath disclose maintaining a routing 
table that is updated from separate IGP and EGP tables. Nor do any of Rekhtar, Alfieri, or 
Jagannath discloses maintaining Exterior Gateway Protocol (EGP) VPN forwarding 
information in a common EGP forwarding table and VPN Interior Gateway Protocol (IGP) 
forwarding information in separate tables for each VPN. 

For example, claims 6, 23, and 30 require "maintaining a first set of information for 
a first layer 3 virtual private network (VPN) context, the first set of information for 
including a first value identifying the first layer 3 VPN context; separately maintaining a 
second set of information for a second layer 3 VPN context, the second set of information 
for including a second value identifying the second layer 3 VPN context, wherein the first 
and second sets of information corresponds to a first and second customers accessing a 
backbone and maintained within a single network element of the backbone, and wherein 
the first and second sets of information include sufficient information to establish the first 
and second layer 3 VPNs contexts with other network elements of the backbone for the 
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first and second customer respectively; . . . maintaining on a single network element a 
single exterior gateway protocol (EGP) table for the first and second laver 3 VPN contexts, 
wherein the single EGP table comprises EGP forwarding entries for the first and second 
layer 3 VPN contexts ; ma intaining on the single network element separate VPN context 
s pecific first routing and interior gateway protocol (IGP) tables for the first laver 3 VPN 
context , wherein the first IGP table comprises IGP forwarding entries for the first layer 3 
VPN context and the first routing table comprises the IGP and EGP forwarding entries for 
the first laver 3 VPN , and wherein the maintaining the first routing table includes 
downloading to the first routing table the first laver 3 VPN context specific entries from the 
EGP and first IGP tables ; and maintaining on the single network element separate VPN 
context specific second routing and IGP tables for the second laver 3 VPN context , wherein 
the second IGP table comprises IGP forwarding entries for the second layer 3 VPN context 
and the second routing table comprises IGP and EGP forwarding entries for the second 
laver 3 VPN , and wherein the maintaining the second routing table includes downloading 
to the second routing table the second laver 3 VPN context specific entries from the EGP 
and second IGP tables ." 

The above quoted limitations are not described or suggested by Rekhtar. While 
there are various uses for the invention as claimed, several such uses are discussed in 
Figure 2A and paragraphs 31, 35, and 37. Thus, while the invention is not limited to the 
uses discussed in these paragraphs, it should be understood that Rekhtar does not enable 
these uses and the above quoted limitations do. 

For at least these reasons, Applicant respectfully submits that the independent 
claims are allowable. The Applicant respectfully submits that the dependant claims are 
allowable for at least the reason that they are dependent on an allowable independent claim. 

Conclusion 

Applicant respectfully submits that the rejections have been overcome by the 
amendments and remarks, and that the Claims as amended are now in condition for 
allowance. Accordingly, Applicant respectfully requests the rejections be withdrawn and 
the Claims as amended be allowed. 
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Invitation for a telephone interview 

The Examiner is invited to call the undersigned at 408-720-8300 if there 
remains any issue with allowance of this case. 

Charge our Deposit Account 
Please charge any shortage to our Deposit Account No. 02-2666. 



Respectfully submitted, 



BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP 



Date: June 4 , 20 08 




Reg. No. 52,161 



1279 Oakmead Parkway 
Sunnyvale, CA 94085-4040 
(408) 720-8300 
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